In dieser Phase sammeln wir Informationen über das Zielsystem. Wir beginnen mit ARP-Scans, um aktive Hosts im Netzwerk zu identifizieren. Anschließend nutzen wir Nmap, um offene Ports und Dienste zu erkennen und eine erste Einschätzung der Sicherheitslage zu erhalten. Ziel ist es, ein umfassendes Bild der Angriffsfläche zu bekommen.
Der ARP-Scan hat einen Host mit der IP-Adresse 192.168.2.138 identifiziert. Dies ist ein vielversprechender erster Schritt.
Nmap zeigt, dass die Ports 21 (FTP), 80 (HTTP) und 25468 (SSH) offen sind. Das FTP und SSH verwundbar sind, werden wir uns auf HTTP konzentrieren, um potenzielle Schwachstellen im Webserver zu finden. Der alternative SSH-Port könnte auf eine bewusste Konfigurationsänderung hindeuten und ist ebenfalls interessant.
Der vollständige Nmap-Scan bestätigt die offenen Ports und liefert zusätzliche Informationen, wie z.B. den HTTP-Server-Header und Einträge in der robots.txt-Datei. Die robots.txt-Datei ist besonders interessant, da sie potenziell sensible Pfade wie /login.php, /dev_shell.php, /lat_memo.html und /passwords.html offenbart. Wir werden diese Pfade später genauer untersuchen.
In dieser Phase konzentrieren wir uns auf die Enumeration des Webservers, um versteckte Dateien, Verzeichnisse und potenzielle Schwachstellen zu finden. Wir verwenden Tools wie wfuzz und nikto, um die Webanwendung zu durchsuchen und Informationen zu sammeln.
Zuerst besuchen wir die entdeckte dev_shell.php im Browser, um sie manuell zu testen.
Die dev_shell.php scheint eine Art Entwicklungsschnittstelle zu sein, die wir später genauer untersuchen werden.
Der Wfuzz-Scan mit der Parameter-Fuzzing-Methode gegen die dev_shell.php lieferte keine brauchbaren Ergebnisse. Das bedeutet, dass wir auf diesem Weg keine offensichtlichen Schwachstellen finden konnten.
Nikto findet einige interessante Punkte: Das Fehlen von Clickjacking- und Content-Type-Headern, die Offenlegung von Inodes über ETags, eine veraltete Apache-Version und das Vorhandensein einer Admin-Login-Seite. Diese Informationen könnten uns später helfen, die Sicherheit des Servers zu kompromittieren. Besonders hervorzuheben ist, dass Nikto die in der robots.txt genannten Pfade als nicht-verboten oder umleitend identifiziert, was bedeutet, dass sie für uns zugänglich sind.
Wir untersuchen nun die robots.txt-Datei genauer.
Die robots.txt-Datei bestätigt die Existenz der Pfade /login.php, /dev_shell.php, /lat_memo.html und /passwords.html. Obwohl sie als "Disallow" gekennzeichnet sind, haben wir bereits festgestellt, dass sie zugänglich sind.
Wir untersuchen nun die /passwords.html Seite.
Die /passwords.html-Seite enthält scheinbar Kontaktinformationen von Mitarbeitern. Dies könnte nützlich sein, um potenzielle Benutzernamen für Brute-Force-Angriffe zu sammeln.
In dieser Phase versuchen wir, einen ersten Zugang zum System zu erhalten. Wir nutzen die gesammelten Informationen, um potenzielle Schwachstellen auszunutzen und uns einen Fuß in das System zu setzen.
Zur Erinnerung: Die Ports 21 (FTP), 80 (HTTP) und 25468 (SSH) sind offen.
Der Versuch, sich anonym per FTP anzumelden, schlägt fehl. Dies deutet darauf hin, dass anonyme Anmeldungen deaktiviert sind.
Wir finden eine Notiz mit folgenden inhalt auf der seite:
Diese Notiz deutet auf frühere Sicherheitsprobleme hin und dass der Administrator "Bob" unzufrieden mit der Sicherheitslage ist. Es wird auch erwähnt, dass eine Datei vom Server entfernt wurde.
Gobuster findet die bereits bekannten Dateien und Verzeichnisse. Dies bestätigt, dass wir keine offensichtlichen versteckten Pfade übersehen haben.
Wir finden eine Notiz mit folgenden inhalt auf der seite:
Der Hinweiß von Bob, das wir ein Web Shell benutzen können, hat uns dazu bewogen die dev_shell.php noch mal anzuschauen.
Die dev_shell.php ermöglicht die Ausführung von Systembefehlen. Dies ist eine kritische Schwachstelle, die wir ausnutzen können, um eine Reverse Shell zu erhalten.
Wir versuchen eine Reverse Shell zu bekommen, indem wir folgenden Befehl eingeben.
Wir richten einen Listener auf Port 5555 ein, um die Reverse Shell zu empfangen.
**Fantastisch!** Die Reverse Shell war erfolgreich. Wir sind jetzt als `www-data` angemeldet.
Wir überprüfen den Inhalt des aktuellen Verzeichnisses. Interessant ist die Datei ".hint".
Der Hinweis legt nahe, eine TTY-Shell zu erzeugen und versteckte Dateien zu überprüfen.
In dieser Phase versuchen wir, unsere Privilegien zu erhöhen, um Root-Zugriff auf das System zu erhalten. Wir suchen nach Konfigurationsfehlern, ausnutzbaren Diensten oder anderen Schwachstellen, die uns helfen könnten, unsere Ziele zu erreichen.
Wir überprüfen, welche Befehle der Benutzer `www-data` mit `sudo` ausführen darf.
Der Benutzer `www-data` darf die Befehle `/usr/bin/service apache2 *` und `/bin/systemctl start ssh` ohne Passwort als Root ausführen. Dies ist eine potenzielle Möglichkeit zur Privilege Escalation.
Wir suchen nach SUID-Dateien, die möglicherweise zur Privilege Escalation ausgenutzt werden können.
Die Liste der SUID-Dateien ist umfangreich. Wir werden diese später genauer untersuchen, um potenzielle Angriffspunkte zu finden.
Wir überprüfen die Berechtigungen der `/etc/passwd`-Datei.
Die `/etc/passwd`-Datei ist nur für Root beschreibbar.
Wir suchen nach Dateien mit aktivierten Capabilities.
Es wurden keine Dateien mit aktivierten Capabilities gefunden.
Wir untersuchen die Home-Verzeichnisse der Benutzer.
Es gibt die Home-Verzeichnisse der Benutzer bob, elliot, jc und seb. Wir werden zuerst das Home-Verzeichnis von "bob" untersuchen.
Die Datei `.old_passwordfile.html` ist vielversprechend. Wir werden sie uns genauer ansehen.
**Bingo!** Hier finden wir potenziell gültige Passwörter für die Benutzer jc und seb. Das Passwort für "seb" sieht stark aus, während das Passwort für "jc" sehr einfach ist.
Wir versuchen, uns als der Benutzer "seb" anzumelden.
Der Benutzer `seb` darf die gleichen Befehle wie `www-data` ohne Passwort als Root ausführen.
Wir versuchen, den SSH-Dienst als Root zu starten.
Der Versuch, den SSH Dienst zu Starten war nicht erfolgreich.
Wir finden die Datei theadminisdumb.txt.
Die Datei enthält ein neues Passwort für den Benutzer Elliot.
Die Liste der Listening Ports.
Die E-Mail Datei mit dem Benutzernamen c0rruptedb1t ist aufgefallen.
Wir versuchen jetzt, die E-mail mit wget herunterzuladen, dafür müssen wir einen kleinen Webserver mit Python starten.
Der versuch die Email herunterzuladen schlug fehl.
Wir benutzen nun das Metasploit Framework.
Um eine vollständige Kontrolle über das System zu erlangen, verwenden wir das Modul `shell_to_meterpreter`, um unsere bestehende Shell-Session in eine Meterpreter-Session umzuwandeln. Meterpreter bietet erweiterte Funktionen und ermöglicht uns, weitere Exploits auszuführen und Informationen zu sammeln.
Jetzt benutzen wir das Modul suggester.
Der Exploit Suggester hat mehrere potenzielle Exploits gefunden, darunter `exploit/linux/local/cve_2021_4034_pwnkit_lpe_pkexec`, der als "vulnerable" eingestuft wird. Dies ist ein vielversprechender Kandidat für die Privilege Escalation.
Wir versuchen jetzt das Exploit zu benutzen.
Wir haben seb:T1tanium_Pa$$word_Hack3rs_Fear_M3 schon als passwort gefunden.
**Fantastisch!** Der Exploit war erfolgreich und wir haben Root-Zugriff erlangt. Unser Ziel ist erreicht.
Dieser Proof of Concept demonstriert, wie die Schwachstelle CVE-2021-4034 (PwnKit) in pkexec ausgenutzt werden kann, um Root-Privilegien auf dem Zielsystem zu erlangen.
CVE-2021-4034 ist eine Privilege-Escalation-Schwachstelle in pkexec, einem SUID-Tool, das Teil von PolicyKit ist. Durch Ausnutzung dieser Schwachstelle kann ein unprivilegierter Benutzer beliebigen Code als Root ausführen.
Wähle das entsprechende Exploit-Modul in Metasploit aus:
Konfiguriere die Optionen des Exploit-Moduls:
Ersetze `[SESSION_ID]` mit der ID deiner Meterpreter-Session.
Ersetze `[DEINE_IP]` mit der IP-Adresse deines Kali-Systems.
(Optional) Passe den LPORT nach Bedarf an.
Führe das Exploit-Modul aus:
Überprüfe, ob eine neue Meterpreter-Session mit Root-Privilegien geöffnet wurde.
Nach erfolgreicher Ausführung des Exploits sollte eine neue Meterpreter-Session mit Root-Privilegien geöffnet werden. Der Befehl `getuid` in dieser Session sollte `Server username: root` zurückgeben.
(Wie im vorherigen Abschnitt gezeigt, liefert der Befehl `getuid` in der neuen Meterpreter-Session `Server username: root`.)
Die Ausnutzung von CVE-2021-4034 ermöglicht es einem Angreifer, vollständige Kontrolle über das System zu erlangen. Dies kann zu Datenverlust, Systemausfällen und anderen schwerwiegenden Folgen führen.
Nachdem wir Root-Zugriff erlangt haben, suchen wir nach den Flags, um den Pentest abzuschließen.
In dieser Phase des Pentests ist es unser Ziel, die erlangten, eingeschränkten Privilegien (in diesem Fall `www-data`) auf das höchste Level – den `root`-Benutzer – auszuweiten. Dies ist oft der anspruchsvollste Teil eines Pentests und erfordert Kreativität, Ausdauer und ein tiefes Verständnis des Zielsystems. Wir werden verschiedene Techniken anwenden, um potenzielle Schwachstellen zu identifizieren und auszunutzen, die uns zu `root`-Rechten verhelfen könnten.
Ein erster wichtiger Schritt ist die Überprüfung, welche Befehle der aktuelle Benutzer (`www-data`) mit `sudo` ausführen darf. Dies gibt uns einen Einblick in potenzielle "Schlupflöcher" in der Systemkonfiguration, die uns zur Eskalation verhelfen könnten.
Die Ausgabe von `sudo -l` zeigt, dass der Benutzer `www-data` zwei Befehle ohne Passwort als `root` ausführen darf: `/usr/bin/service apache2 *` und `/bin/systemctl start ssh`. Dies ist eine signifikante Entdeckung! Insbesondere die Möglichkeit, den SSH-Dienst zu starten, könnte uns einen direkten Weg zu `root`-Rechten eröffnen, da wir den Dienst möglicherweise so konfigurieren können, dass er sich anders verhält als erwartet. Wir werden zunächst die `apache2`-Option untersuchen.
Als nächstes suchen wir nach SUID-Dateien. SUID (Set User ID) ist ein spezielles Berechtigungs-Bit, das es einem Benutzer ermöglicht, eine ausführbare Datei mit den Rechten des Eigentümers der Datei auszuführen (in den meisten Fällen `root`). Wenn wir eine SUID-Datei finden, die eine Schwachstelle aufweist, könnten wir diese ausnutzen, um Code als `root` auszuführen.
Die Liste der SUID-Dateien ist ziemlich lang. Einige dieser Dateien sind bekannte Kandidaten für Privilege-Escalation-Angriffe (z.B. `pkexec`, `exim4`, `pppd`, `mount`, `umount`). Wir werden diese Dateien genauer untersuchen, um zu sehen, ob wir eine Möglichkeit finden, sie auszunutzen. Die schiere Anzahl an SUID-Dateien deutet auf eine potenziell unsichere Konfiguration hin.
Eine weitere wichtige Information ist, wie die `/etc/passwd`-Datei geschützt ist. Diese Datei enthält die Benutzerkonten des Systems und (zumindest historisch) auch Hashes der Passwörter.
Die `/etc/passwd`-Datei ist nur für `root` beschreibbar. Dies ist die Standardkonfiguration und schützt die Benutzerkonten vor Manipulation durch unprivilegierte Benutzer. Wäre die Datei beschreibbar, könnten wir potenziell einen neuen Benutzer mit `root`-Rechten hinzufügen.
Capabilities sind eine modernere und präzisere Methode zur Vergabe von Privilegien als SUID. Anstatt einer Datei alle Rechte des Eigentümers zu gewähren, ermöglichen Capabilities die Zuweisung spezifischer Rechte (z.B. die Möglichkeit, Netzwerkpakete zu senden oder Systemzeit zu ändern). Wir suchen nach Dateien mit aktivierten Capabilities.
Es wurden keine Dateien mit aktivierten Capabilities gefunden. Dies bedeutet, dass Capabilities in diesem System nicht zur Privilege Escalation verwendet werden können (zumindest nicht auf offensichtliche Weise).
Nachdem wir einige grundlegende Systeminformationen gesammelt haben, ist es an der Zeit, die Home-Verzeichnisse der Benutzer zu inspizieren. Home-Verzeichnisse enthalten oft Konfigurationsdateien, Skripte oder andere sensible Informationen, die uns bei der Privilege Escalation helfen könnten.
Es gibt die Home-Verzeichnisse der Benutzer `bob`, `elliot`, `jc` und `seb`. Wir werden diese Verzeichnisse systematisch untersuchen, beginnend mit dem Verzeichnis `bob`, da der Name `bob.vuln` auch der Domainname ist und dies auf eine gewisse Bedeutung hindeuten könnte.
Die Datei `.old_passwordfile.html` sticht sofort ins Auge. Der Name deutet darauf hin, dass sie möglicherweise alte Passwörter enthält, was eine Goldmine für uns sein könnte. Wir werden diese Datei sofort genauer unter die Lupe nehmen. Andere Dateien wie `.bash_history` und `.ssh` könnten auch interessant sein, werden aber erst später untersucht.
**Jackpot!** Diese Datei enthält potenziell gültige Passwörter für die Benutzer `jc` und `seb`. Das Passwort für `seb` (`T1tanium_Pa$$word_Hack3rs_Fear_M3`) ist komplex und deutet darauf hin, dass `seb` sich der Sicherheit bewusst ist (oder zumindest war). Das Passwort für `jc` (`Qwerty`) ist hingegen extrem einfach und unsicher. Wir werden zunächst versuchen, uns als `seb` anzumelden, da dies der vielversprechendste Weg zu sein scheint.
Wir versuchen nun, uns als der Benutzer `seb` anzumelden, um zu sehen, ob das gefundene Passwort noch gültig ist.
(Nach Eingabe des Passworts `T1tanium_Pa$$word_Hack3rs_Fear_M3`...)
**Erfolg!** Wir haben uns erfolgreich als der Benutzer `seb` angemeldet. Interessanterweise darf auch `seb` die gleichen Befehle wie `www-data` ohne Passwort als `root` ausführen. Dies bestätigt unsere Vermutung, dass die Systemkonfiguration einige Sicherheitslücken aufweist. Wir werden nun versuchen, diese Befehle auszunutzen, um `root`-Rechte zu erlangen.
Wir erinnern uns daran, dass wir mit dem Befehl `/bin/systemctl start ssh` den SSH-Dienst als `root` starten dürfen. Wir werden versuchen, den Dienst so zu konfigurieren, dass er sich anders verhält als erwartet, z.B. indem wir einen Port-Forwarding einrichten oder einen anderen Benutzer mit `root`-Rechten anmelden.
Der Versuch, den SSH Dienst zu Starten war nicht erfolgreich.
Auf der Suche nach weiteren Informationen, die uns bei der Privilege Escalation helfen könnten, stolpern wir über eine interessante Datei im Home-Verzeichnis von `elliot`: `theadminisdumb.txt`.
Diese Datei ist eine Goldgrube! Sie bestätigt nicht nur die schlechte Sicherheitslage, sondern liefert auch ein neues Passwort für den Benutzer `elliot`: `theadminisdumb`. Dies ist ein klarer Hinweis darauf, dass `elliot` frustriert ist und beschlossen hat, ein leicht zu merkendes Passwort zu verwenden. Wir werden dieses Passwort sofort ausprobieren.
Die Liste der Listening Ports.
Die E-Mail Datei mit dem Benutzernamen c0rruptedb1t ist aufgefallen.
Wir versuchen jetzt, die E-mail mit wget herunterzuladen, dafür müssen wir einen kleinen Webserver mit Python starten.
Um eine vollständige Kontrolle über das System zu erlangen, verwenden wir das Modul `shell_to_meterpreter`, um unsere bestehende Shell-Session in eine Meterpreter-Session umzuwandeln. Meterpreter bietet erweiterte Funktionen wie das Hochladen und Ausführen von Dateien, das Sammeln von Informationen über das System und das Ausführen weiterer Exploits. Der erfolgreiche Abschluss dieses Schritts ist entscheidend für den nächsten Schritt, die Privilege Escalation.
Nachdem wir eine Meterpreter-Session haben, nutzen wir das Modul `exploit_suggester`, um potenzielle Exploits zu identifizieren, die uns zu `root`-Rechten verhelfen könnten. Dieses Modul durchsucht das System nach bekannten Schwachstellen und schlägt Exploits vor, die für das jeweilige System geeignet sind.
Der Exploit Suggester hat mehrere potenzielle Exploits gefunden. Besonders interessant ist `exploit/linux/local/cve_2021_4034_pwnkit_lpe_pkexec` (PwnKit), der als "The target is vulnerable" markiert ist. Dies deutet darauf hin, dass das System anfällig für diese bekannte Schwachstelle ist, die es einem unprivilegierten Benutzer ermöglicht, `root`-Rechte zu erlangen. Wir werden diesen Exploit als unseren primären Angriffsvektor verwenden.
Wir versuchen nun, das PwnKit-Exploit zu verwenden, um unsere Privilegien zu erhöhen. Wir wählen das entsprechende Modul in Metasploit aus und konfigurieren die erforderlichen Optionen.
Die Konfiguration des PwnKit-Exploits erfordert die Angabe der Session-ID und eines beschreibbaren Verzeichnisses. Wir verwenden `/tmp` als beschreibbares Verzeichnis, da es normalerweise für alle Benutzer beschreibbar ist.
Der Exploit wurde ausgeführt und scheint erfolgreich gewesen zu sein! Um sicherzustellen, dass wir tatsächlich `root`-Rechte haben, werden wir eine neue Meterpreter-Session öffnen und den Befehl `getuid` ausführen.
**Volltreffer!** Der Befehl `getuid` gibt `Server username: root` zurück. Dies bestätigt, dass wir erfolgreich `root`-Rechte erlangt haben. Der Pentest ist somit erfolgreich abgeschlossen!
Dieser Proof of Concept (PoC) demonstriert detailliert, wie die Schwachstelle CVE-2021-4034 (PwnKit) in `pkexec` ausgenutzt werden kann, um `root`-Privilegien auf dem Zielsystem zu erlangen. Ziel ist es, die Realisierbarkeit des Angriffs zu demonstrieren und die Notwendigkeit von Sicherheitsmaßnahmen zu unterstreichen.
CVE-2021-4034 ist eine kritische Privilege-Escalation-Schwachstelle in `pkexec`, einem SUID-Tool, das Teil von PolicyKit ist. PolicyKit wird verwendet, um die Privilegien von Prozessen zu verwalten. Die Schwachstelle ermöglicht es einem unprivilegierten Benutzer, durch Manipulation der Umgebungsvariablen beliebigen Code mit `root`-Rechten auszuführen. Dies geschieht, weil `pkexec` die Anzahl der Argumente falsch behandelt und dadurch ein Array außerhalb der Grenzen gelesen werden kann.
Um diesen PoC erfolgreich durchzuführen, sind folgende Voraussetzungen erforderlich:
Die folgenden Schritte beschreiben detailliert, wie CVE-2021-4034 mit Metasploit ausgenutzt wird:
Starte die Metasploit-Konsole (`msfconsole`) auf deinem Kali-System.
Wähle das entsprechende Exploit-Modul in Metasploit aus:
Dieser Befehl lädt das PwnKit-Exploit-Modul in die Metasploit-Konsole.
Konfiguriere die Optionen des Exploit-Moduls:
Zuerst musst du die `SESSION`-Option auf die ID deiner aktiven Meterpreter-Session setzen. Führe den Befehl `sessions` aus, um die verfügbaren Sessions aufzulisten und die entsprechende ID zu identifizieren.
Ersetze `[SESSION_ID]` mit der ID deiner Meterpreter-Session (z.B. `2`).
Als Nächstes musst du die `LHOST`-Option auf die IP-Adresse deines Kali-Systems setzen. Dies ist die IP-Adresse, an die die Reverse Shell gesendet wird, nachdem der Exploit erfolgreich ausgeführt wurde.
Ersetze `[DEINE_IP]` mit der IP-Adresse deines Kali-Systems (z.B. `192.168.2.137`).
Optional kannst du den `LPORT` anpassen, den Port, an dem dein Kali-System auf die Reverse Shell wartet.
Stelle sicher, dass du die Optionen korrekt konfiguriert hast, indem du den Befehl `options` ausführst.
Führe das Exploit-Modul aus:
Überprüfe, ob eine neue Meterpreter-Session mit `root`-Privilegien geöffnet wurde. Wenn der Exploit erfolgreich war, sollte eine neue Session erstellt werden.
Interagiere mit der neuen Session:
Ersetze `[NEUE_SESSION_ID]` mit der ID der neuen Meterpreter-Session.
Bestätige die `root`-Privilegien:
Wenn alles erfolgreich verlaufen ist, sollte die Ausgabe `Server username: root` lauten.
Nach erfolgreicher Ausführung des Exploits sollte eine neue Meterpreter-Session mit `root`-Privilegien geöffnet werden. Der Befehl `getuid` in dieser Session sollte `Server username: root` zurückgeben, was beweist, dass wir erfolgreich `root`-Rechte erlangt haben.
Die screenshots im vorherigen Abschnitt zeigen bereits, dass der Befehl `getuid` in der neuen Meterpreter-Session `Server username: root` zurückgibt.
Die Ausnutzung von CVE-2021-4034 ermöglicht es einem Angreifer, vollständige Kontrolle über das System zu erlangen. Dies kann zu schwerwiegenden Folgen führen, darunter:
Um das Risiko einer Ausnutzung von CVE-2021-4034 zu minimieren, sollten folgende Maßnahmen ergriffen werden:
Nachdem wir erfolgreich `root`-Zugriff erlangt haben, ist es unser Ziel, die "Flags" zu finden. Flags sind in der Regel spezielle Textdateien, die den Abschluss eines Pentests oder einer Capture-The-Flag (CTF)-Übung markieren. Sie dienen als Beweis dafür, dass wir das System erfolgreich kompromittiert haben und unsere Ziele erreicht haben.
Nachdem wir erfolgreich `root`-Zugriff erlangt haben, ist es unser Ziel, die "Flags" zu finden. Flags sind in der Regel spezielle Textdateien, die den Abschluss eines Pentests oder einer Capture-The-Flag (CTF)-Übung markieren. Sie dienen als Beweis dafür, dass wir das System erfolgreich kompromittiert haben und unsere Ziele erreicht haben. In diesem Fall suchen wir nach den Dateien `root.txt` und `user.txt`.
Flag: c7d0a8de1e03b25a6f7ed2d91b94dad6
Flag: 5C42D6BB0EE9CE4CB7E7349652C45C4A
Die Flags wurden gefunden! Dies bestätigt, dass wir alle Ziele des Pentests erreicht haben. Der Pentest war erfolgreich.